The term “cloud computing” describes an approach for dynamically providing abstracted information technology (IT) infrastructures (for example computing capacity, data memory, network capacities or else finished software) in a manner adapted to the requirements via a network. From the point of view of the user, the infrastructure provided appears to be remote and opaque, like wrapped in a “cloud”.
With this approach, part of the IT landscape (in this context, hardware such as the computing center and data memory, and software, for instance) is no longer operated on the user side or provided at the user's location but rather is rented as a service from one or more providers, for example, these providers being able to be geographically remote. The applications or data are no longer situated (only) on the local computer or a (company) computing center but rather in the “cloud”. In this case, the cloud may be part of the Internet or may include the latter.
Cloud computing makes it possible to provide network-based applications in new business models. Services in the cloud may be provided on different levels in this case:
(a) Infrastructure (IaaS):                A potential customer “rents” computing power in order to implement his own services. For this purpose, cloud computing uses computing centers that are either concentrated at one location or may be interconnected in a distributed manner in order to provide flexible services. Virtual machines are implemented on these computers. The customers load data (for example images) into the cloud and processing is effected in the computing center without user interaction.        
(b) Platform (PaaS):                The customer gains access to a platform that includes, on the one hand, the infrastructure for providing a service as well as particular software parts (for example middleware) that may be used to create services. The service created thereby is a web application, for example.        
(c) Software (SaaS):                A cloud provider provides a network-based application that is used by the customer using his browser. In this case, documents or data records may be created or processed by the customer using the browser.        
The outsourcing of applications and data may be a security threat since data and documents are stored with the cloud provider and—depending on the type of cloud or implementation of the service—are also processed there (that is to say data are also accessed in the cloud).
For example, local system administrators of the service operator (also referred to as cloud system administrators) therefore have any desired access to the data if no special protective measures are taken. In addition, other attacks on the data are possible and the user who outsources his data to the cloud does not know what security measures have been taken for his data and whether the measures are effective. In other words, the user cannot estimate or may only poorly estimate the actual threat to his possibly confidential or sensitive data.
Continuous protection of the data from unauthorized access and, in particular, shielding from the system administrators (this is also referred to as “operator shielding”) are important prerequisites for outsourcing critical (for example security-relevant and/or confidential) data to the cloud. Continuous protection that is independent of the security measures provided by the cloud provider may be achieved only when the owner of the data has control over access to the data and the security measures required for this purpose.
A document-based cloud application includes a program running on the server (also referred to as a server application or AppS) and a program that runs locally with the user (also referred to as a client application or AppC) and may run in a web browser. In this case, depending on the architecture, the division of software between the server application and the client application may be scaled or configured differently.
A widespread method for protecting data in cloud applications is the encryption of the data. There are two variants in this case:    (A) The encryption is carried out by the owner of the data before documents are transferred to the cloud application. The owner manages the corresponding keys. The documents are continuously protected when being transported to and from the cloud and during storage in the cloud.    (B) The cloud application encrypts documents upon arrival or when being stored on local data storage media inside the cloud, the cloud provider managing an encryption key. The secure transport of the documents may be explicitly ensured by using a secure channel (for example using a secure hypertext transfer protocol, “https”).
In case (A), it is not possible to process the documents and data in the cloud but only to purely store them. Useful processing of documents is therefore possible, only after decryption by a user, locally on his computer. The secure management of the key material used may be made available to all authorized users who intend to view or process the documents is problematic and complicated in this case.
Since, in case (B), the encryption is carried out by the rented software inside the cloud, there are points of attack for circumventing the encryption for cloud system administrators, for example. In order to securely implement such a solution, known methods also require, in addition to technical methods, organizational measures that are usually a weak point. The owner of the data may therefore place a considerable amount of trust in the cloud provider as the operator of the cloud application to the effect that the cloud provider securely implements an encryption solution.
Digital rights management (DRM: Digital Rights Management) is a system for companies, referred to as EDRM (Enterprise Digital Rights Management), that provides access protection for documents irrespective of their storage location. A protected document may be opened and processed by an authorized user only in accordance with his access rights that are valid for this, irrespective of where the document has been stored or how it has been transmitted. An unauthorized user without access rights cannot start anything with a copy of the document that he has received by email, for example, or has discovered on a USB stick.
However, in order to use EDRM, the applications are be specifically adapted for EDRM, that is to say the applications are supplemented with an EDRM functionality, since the basis of EDRM is the encryption of documents. The publisher of a document encrypts the document before he releases the document; the publisher also additionally defines the rights for users and/or groups for the document. The encrypted file including the access rights is sent to an EDRM server.
In addition to the EDRM server that is the central part of the EDRM approach, there is an EDRM client that is installed on every computer intended to process EDRM protected documents. The EDRM client communicates with the EDRM server in order to determine the key and the rights of a user with respect to a document. The EDRM server provides the key only after the user has been authenticated with respect to the EDRM server. The EDRM client transfers the rights to an application that has EDRM capability and is responsible for complying with the rights. The EDRM client decrypts the document and carries out renewed encryption that is possibly required later. The key is kept secret, even from a user with administration rights, by the EDRM client using code obfuscation and other technologies.
FIG. 1 depicts an architecture of a known EDRM approach. An EDRM client 101 is connected to an EDRM server 102. The EDRM server is connected to a further EDRM client 103, for example a computer belonging to a customer, a supplier or a business partner. The EDRM clients 101, 103 and the EDRM server may be functionalities (comprising hardware and/or software) that are provided or installed on computers, for example personal computers.
A (protected) document is created as follows:    (1) The author/owner creates the document.    (2) The author/owner encrypts the document with the aid of the EDRM client 101 and specifies the access rights in a format specified by the EDRM system, a EDRM policy. In this case, it is possible to describe and allocate access rights in a detailed manner: for example, it is possible to define for each authorized person whether the latter may read, print, change or redistribute the document. A period of time during which access is allowed may also be limited (for example in a personal manner).    (3) The encrypted document is sent, together with the rights, to the EDRM server 102.
The protected document is accessed as follows:    (1) A user loads the protected document into an application (for example an application running locally on his computer). He locally needs the EDRM client 103 for access. This EDRM client 103 is connected to the local device and to the user using cryptographic protocol.    (2) The EDRM client 103 contacts the EDRM server 102 that responds with a request to authenticate the user.    (3) If the authentication is successful, the EDRM client 103 receives the rights object with the EDRM policy and the decryption key.    (4) The EDRM client 103 decrypts the document and forwards it to the application. Actions on the document such as printing or processing are carried out by the application only if the EDRM client 103 allows this according to the rights specified in the EDRM policy. This means that the application may be configured to the EDRM functionality.
It is possible to use existing EDRM solutions in connection with a cloud and to thus protect documents through encryption. EDRM may therefore be considered to be a functionality that includes an encryption method with key management. In a similar manner to variants (A) and (B) described above, the owner of the document may operate the EDRM server 102 (and may therefore have the key management under his control) or else the cloud provider may provide the EDRM server 102.
With respect to the cloud application, documents may be stored with EDRM protection, with the result that documents may be locally processed only by authorized users (according to the EDRM policy) on their device. The following problems arise in this case:    (a) If documents are intended to be processed online by the server application (AppS) (for example for editing a document or for converting it into a PDF file), corresponding reading or processing rights are granted to the server in known EDRM systems. All processing operations that are carried out by the server application are therefore carried out with the EDRM authorization of the server, that is automatically granted, in particular without any previous user authentication. This is a point of attack that may be used, for example, by system administrators or external attackers.    (b) Existing EDRM systems cannot distinguish between processing by the server (for example search indexing or checking for viruses) and processing by the (authorized) user. Even if the processing is carried out by an authorized user who edits a document, for example, it is not possible to understand in the EDRM system who has accessed the document since only access by the server is entered in the corresponding log entries on the EDRM server.    (c) The two parts of the application, that is to say the server application and the client application, run in different contexts, that is to say on the server and locally on the user's computer, with different security requirements. Depending on the risk assessment, an owner of a document will more likely allow processing by the client application or else by the server application, for example. Furthermore, depending on the division of the application, it may be desirable for the client application to be allocated different rights than the server application. For example, a right for printing a document is less useful for a server application than, for example, a right for converting the document into a PDF file. Without a distinction between the rights of the server application and the client application, the semantics of some rights are unclear, that may result in problems when specifying the rights for a document.